Amazon Redshift: 『パフォーマンスチューニングテクニック Top 10』手順の実践(6).キュースロットをウエイトしているクエリ
当エントリは先日投稿したシリーズ『『Amazon Redshiftのパフォーマンスチューニングテクニック Top 10』手順実践』の第6弾です。課題#6の『キュースロットをウエイトしているクエリ』について内容を見て行きたいと思います。
このトピックではパフォーマンス改善のポイントとして『WLM(Workload Management)』について言及しています。WLMの公式ドキュメント解説はこちら。
当ブログ内でも、WLMに関するネタは幾つか投稿があります。主だったところだとこの辺り。
- Amazon Redshift 動的ワークロードマネジメント(WLM)を試してみた ｜ Developers.IO
- Amazon Redshift: WLM(Workload Management)のクエリ同時実行制限値が緩和されました ｜ Developers.IO
その他WLMに関して言及している情報はこの辺りがとても参考になります。
キューイングされているクエリの特定
この問題を解決する為にはまず、どのクエリがキューに溜まったままになっているかを判別する必要があります。以下のクエリを実行する事でその情報を得る事が出来ます。
クエリの実行結果は以下の様な形式で得る事が出来ます。実行環境は特にクエリを頻繁に実行し、キューに溜まるという状況でも無かった為、システム系のクエリが引っ掛かる程度でした。当トピックの問題を解決する様な状況であれば、この部分に実稼働している(要因となりうる)クエリが表示される形となります。
query | querytxt | queue_start_time | class | slots | queue_seconds | exec_seconds | total_seconds ---------+------------------------------------------------------------+----------------------------+-------+-------+---------------+--------------+--------------- 8888888 | Select * from pg_internal.redshift_auto_health_check_29166 | 2016-08-26 15:10:14.402869 | 1 | 1 | 3 | 0 | 3 9999999 | select system_status from stv_gui_status; | 2016-08-26 15:10:12.810281 | 1 | 1 | 1 | 3 | 5
ちなみに、『キューが溜まる』というのはどのような状況を指すのでしょうか。公式ドキュメントには以下の様な記載があります。1つの実行キューに全てのクエリが溜まってしまい、結果実行を待つ事になってしまっている状況、という訳ですね。
時折、キューにアサインされたクエリ、もしくはユーザが極めて重い処理を実行し、他ユーザのクエリーがそのキュースロットが空くのを待つことになる場合があります。この間はクエリーを全て実行できておらず、これは並列度を増加させる必要性のサインです。
クエリキューの定義 - Amazon Redshift
クラスターがこれまでどれだけの並列性を必要としたかを確認
対象となっているクラスタがこれまでにどの程度の並列性を必要としたかを確認するには以下のクエリを実行して確認します。
実行結果は以下の様な形で出力されます。
- service_class:
- WLMの構成ファイルで定義されたサービスクラスのID
- max_wlm_concurrency:
- サービスクラスの現在の同時実行数
- max_service_class_slots:
- その時点での最大WLMクエリスロット数
- max_slots_ts:
- max_service_class_slotsが発生した最も直近の時間
- last_queued_time:
- service_classにおけるキューイングが発生した最も直近の時間。キューイングが無い場合はNULL表示となる
service_class | max_wlm_concurrency | max_service_class_slots | max_slots_ts | last_queued_time
---------------+---------------------+-------------------------+----------------------------+----------------------------
6 | 12 | 4 | 2016-08-25 23:47:11.727718 | 2016-08-11 02:21:19.332183
(1 行)
ちなみに『スロット』とはどういう意味になるのでしょうか。こちらもAWS公式ドキュメントに記載があります。スロットの数＝同時実行レベルと読み替えて良さそうです。
ちなみに『スロット』というと私個人的には『ミリオンスロット！』のアレを思い出してしまうお年頃です(しろめ
1時間単位での利用履歴分析を確認
時間単位で、どの時間帯にどれだけの並列性を必要としたかを確認するSQLが以下のものとなります。
実行結果は以下の様な形で生成されます。内容を確認してみると23:00 - 23:59の時間帯で『4』という値を確認する事が出来ますね。
service_class | max_wlm_concurrency | day | hour | max_service_class_slots
---------------+---------------------+------------+---------------+-------------------------
6 | 12 | 2016-08-22 | 5:00 - 5:59 | 2
6 | 12 | 2016-08-22 | 6:00 - 6:59 | 1
6 | 12 | 2016-08-22 | 7:00 - 7:59 | 2
6 | 12 | 2016-08-22 | 8:00 - 8:59 | 2
6 | 12 | 2016-08-22 | 9:00 - 9:59 | 2
6 | 12 | 2016-08-22 | 10:00 - 10:59 | 2
6 | 12 | 2016-08-22 | 14:00 - 14:59 | 1
6 | 12 | 2016-08-22 | 18:00 - 18:59 | 2
6 | 12 | 2016-08-22 | 19:00 - 19:59 | 2
6 | 12 | 2016-08-22 | 20:00 - 20:59 | 1
6 | 12 | 2016-08-22 | 22:00 - 22:59 | 1
6 | 12 | 2016-08-22 | 23:00 - 23:59 | 4
6 | 12 | 2016-08-23 | 0:00 - 0:59 | 2
6 | 12 | 2016-08-23 | 1:00 - 1:59 | 3
6 | 12 | 2016-08-23 | 2:00 - 2:59 | 3
6 | 12 | 2016-08-23 | 3:00 - 3:59 | 2
6 | 12 | 2016-08-23 | 4:00 - 4:59 | 1
6 | 12 | 2016-08-23 | 5:00 - 5:59 | 1
6 | 12 | 2016-08-23 | 6:00 - 6:59 | 1
6 | 12 | 2016-08-23 | 7:00 - 7:59 | 3
6 | 12 | 2016-08-23 | 8:00 - 8:59 | 2
6 | 12 | 2016-08-23 | 9:00 - 9:59 | 2
6 | 12 | 2016-08-23 | 10:00 - 10:59 | 1
6 | 12 | 2016-08-23 | 14:00 - 14:59 | 1
6 | 12 | 2016-08-23 | 18:00 - 18:59 | 2
6 | 12 | 2016-08-23 | 19:00 - 19:59 | 2
6 | 12 | 2016-08-23 | 20:00 - 20:59 | 1
6 | 12 | 2016-08-23 | 22:00 - 22:59 | 1
6 | 12 | 2016-08-23 | 23:00 - 23:59 | 4
6 | 12 | 2016-08-24 | 0:00 - 0:59 | 2
6 | 12 | 2016-08-24 | 1:00 - 1:59 | 2
6 | 12 | 2016-08-24 | 2:00 - 2:59 | 3
6 | 12 | 2016-08-24 | 3:00 - 3:59 | 3
6 | 12 | 2016-08-24 | 4:00 - 4:59 | 1
6 | 12 | 2016-08-24 | 5:00 - 5:59 | 2
6 | 12 | 2016-08-24 | 6:00 - 6:59 | 2
6 | 12 | 2016-08-24 | 7:00 - 7:59 | 1
6 | 12 | 2016-08-24 | 8:00 - 8:59 | 2
6 | 12 | 2016-08-24 | 9:00 - 9:59 | 2
6 | 12 | 2016-08-24 | 10:00 - 10:59 | 1
6 | 12 | 2016-08-24 | 11:00 - 11:59 | 1
6 | 12 | 2016-08-24 | 14:00 - 14:59 | 1
6 | 12 | 2016-08-24 | 15:00 - 15:59 | 1
6 | 12 | 2016-08-24 | 18:00 - 18:59 | 2
6 | 12 | 2016-08-24 | 19:00 - 19:59 | 2
6 | 12 | 2016-08-24 | 20:00 - 20:59 | 1
6 | 12 | 2016-08-24 | 22:00 - 22:59 | 1
6 | 12 | 2016-08-24 | 23:00 - 23:59 | 4
6 | 12 | 2016-08-25 | 0:00 - 0:59 | 1
6 | 12 | 2016-08-25 | 1:00 - 1:59 | 3
6 | 12 | 2016-08-25 | 2:00 - 2:59 | 3
6 | 12 | 2016-08-25 | 3:00 - 3:59 | 3
6 | 12 | 2016-08-25 | 4:00 - 4:59 | 2
6 | 12 | 2016-08-25 | 5:00 - 5:59 | 2
6 | 12 | 2016-08-25 | 6:00 - 6:59 | 2
6 | 12 | 2016-08-25 | 7:00 - 7:59 | 3
6 | 12 | 2016-08-25 | 8:00 - 8:59 | 2
6 | 12 | 2016-08-25 | 9:00 - 9:59 | 1
6 | 12 | 2016-08-25 | 10:00 - 10:59 | 1
6 | 12 | 2016-08-25 | 11:00 - 11:59 | 1
6 | 12 | 2016-08-25 | 12:00 - 12:59 | 2
6 | 12 | 2016-08-25 | 14:00 - 14:59 | 1
6 | 12 | 2016-08-25 | 18:00 - 18:59 | 2
6 | 12 | 2016-08-25 | 19:00 - 19:59 | 2
6 | 12 | 2016-08-25 | 20:00 - 20:59 | 1
6 | 12 | 2016-08-25 | 22:00 - 22:59 | 1
6 | 12 | 2016-08-25 | 23:00 - 23:59 | 4
6 | 12 | 2016-08-26 | 0:00 - 0:59 | 2
6 | 12 | 2016-08-26 | 1:00 - 1:59 | 1
6 | 12 | 2016-08-26 | 2:00 - 2:59 | 2
6 | 12 | 2016-08-26 | 3:00 - 3:59 | 2
6 | 12 | 2016-08-26 | 4:00 - 4:59 | 2
6 | 12 | 2016-08-26 | 5:00 - 5:59 | 2
6 | 12 | 2016-08-26 | 6:00 - 6:59 | 1
6 | 12 | 2016-08-26 | 7:00 - 7:59 | 2
6 | 12 | 2016-08-26 | 8:00 - 8:59 | 2
6 | 12 | 2016-08-26 | 9:00 - 9:59 | 3
6 | 12 | 2016-08-26 | 10:00 - 10:59 | 2
6 | 12 | 2016-08-26 | 11:00 - 11:59 | 2
6 | 12 | 2016-08-26 | 12:00 - 12:59 | 1
6 | 12 | 2016-08-26 | 14:00 - 14:59 | 1
6 | 12 | 2016-08-26 | 18:00 - 18:59 | 1
6 | 12 | 2016-08-26 | 19:00 - 19:59 | 1
6 | 12 | 2016-08-26 | 20:00 - 20:59 | 1
6 | 12 | 2016-08-26 | 21:00 - 21:59 | 1
6 | 12 | 2016-08-26 | 22:00 - 22:59 | 1
6 | 12 | 2016-08-26 | 23:00 - 23:59 | 2
(87 行)
これらの情報を以って、キューの分割検討及び個別キューの設定(最大8つまで設定可能)、キューに割り当てる際のクエリの実行方法について変更・改善を施していく形になります。ただこの値、無闇に増やせば良いと言うものでもなく、増やしたら増やしたで影響が及ぶ部分もあるので注意が必要です。
並列性の増加はより多くのクエリーを実行可能にしますが、一方で割当られたメモリ空間を共有しているためにクエリあたりのメモリが減少する（メモリ割当てを増やさない限り）という点には注意が必要です。並列性を増加させると、いくつかのクエリを実行するためにテンポラリーディスクへの書き出しが必要になる場合があります。この調整は次の課題で検討します。
まとめ
以上、『Amazon Redshiftのパフォーマンスチューニングテクニック Top 10』トピック6つめ、"キュースロットをウエイトしているクエリ"に関する対処方法のご紹介でした。7つ目以降のトピックについても、こんな感じで読み解きつつ実践して行きたいと思います。
![[レポート]Amazon Redshiftで生成AIのためのデータ戦略を構築 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[Redshift] テーブルへのアクセス権付与権限について調べてみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-63f1274931b942e9a92e601c1127ad73/cfe87ec6d62fa2fc3c474ed4cb2f6c2e/amazon-redshift)
